Increased connectivity between various electronic devices in recent years has lead to an increased need for receiving multicast data. In general, electronic devices may rely on Internet Group Management Protocol (IGMP) and/or Multicast Listener Discovery (MLD) for multicast data communication. A group membership report packet is needed to establish multicast data transmission. The group membership report packet may be transmitted according to “robustness variable” number, e.g., transmitted 2 times, 3 times, etc. However, in IGMP or MLD protocol, the group membership report packet may not be received (or dropped), e.g., a bridge or L2 switch may be in transient state and not forward the packet or it may be recovering from a reboot and may not forward state, in initializing state, recovering from a crash in the midst of a fail-over procedure in a live-live redundant system scenarios, etc. The system delays for a long time, e.g., 125 seconds, if the group membership report packet is transmitted a number of times according to the robustness variable but not received.
It is appreciated that the robustness variable number may be set, e.g., 2, in the protocol. Accordingly, the group membership report packet transmission is terminated after the set number of times the group membership report packets are transmitted and the system delays for a long time, e.g., 125 seconds, before another query is received, after which the system may transmit another robustness variable number of group membership report packets, if any.
Unfortunately, standards such as RFC3376 Sec 4.1.6 for IGMP and RFC3810 Sec 5.1.8 for MLD specifications are limited by allowing only a maximum value for the robustness variable, e.g., 7. Furthermore, increasing the number of robustness variable while might alleviate the packet loss issue, it unnecessarily increase chattiness of protocols under normal conditions.